IBIS Macromodel Task Group Meeting date: 16 April 2013 Members (asterisk for those attending): Agilent: Fangyi Rao Radek Biernacki Altera: David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari * Hassan Rafat Ron Olisar Mentor Graphics: John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: Walter Katz * Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Mike L: Will not be able to join Apr 30, possibly not Apr 23 either -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad update BIRD 160 draft with Bob's comments - Done, there have been two revisions - Arpad try to apply BIRD 158 shortcut language to his BIRDs 116-118 - In progress - Walter write new BIRD for repeater/retimer pin keywords - In progress ------------- New Discussion: Interconnect Task Group report: - Michael M: Went over open EMD issues last week - EMD draft 5 has been issued and will be discussed this week Analog BIRDs: - Arpad: We will schedule a vote for recommendation to open forum - Walter: The labels BIRD should be ready for voting too, would like to discuss - Arpad showed BIRD 160.1 draft 2 - Todd: - There are multiple ways to draw a waveform with a given 20%-80% dv/dt, even for an ideal 50 ohm output with no V-T data - A perfectly trapezoidal ramp has very high harmonics - With bandwidth limiting rolloff the results are very different - The D_to_A has the same problem, wave shape is not specified - Arpad: We don't know where to start filtering harmonics - I always assumed perfect trapezoidal - Todd: That is the intent but but not the letter of the law - Michael M: Long ago there were discussions about [Ramp] with minimal V-T tables - This would avoid uncertainty - Is there a minimum number of points for [Ramp]? - Arpad: This is independent of BIRD 160 - There could be another BIRD for D_to_As - Todd: Models written with this can work differently in two simulators - Michael M: Let us say this would have to be closed in the next spec version - Arpad: Even with a 4 point V-T table we can't be sure about wave shape - Todd: The problem here is we place a passive circuit in place of the model, and we don't know what the stimulus is - A simple circuit demonstrates that eye margin is very different depending on stimulus - Bob: A sharp ramp stimulus and s-param can give desired results - Trying to use ramp time for shaping is already an approximation - Todd: It needs to be unambiguous - Arpad: The language implies straight ramp edges - Todd: There are tools implementing it in multiple ways - Michael M: Maybe BIRD 160 should address [Ramp] specifically - Todd: We need to close the [Ramp] and D_to_A issues the same way - Meanwhile models should not be built with this - Bob: How does this work with AMI? - Todd: It's broken - One suggestion is [Ramp] subparams to define rolloff - The would provide continuity with what simulators already do - One question is about the impact on existing models - We should create a simple demonstration model and try to get consistent results - Arpad: How can [Ramp] be anything but a straight line? - Todd: All real circuits are band limited - Bob: I implemented [Ramp] with rounded upper and lower halves - We should use some other technique to give driver frequency response - Arpad showed a section of BIRD 160 defining D_to_A - Arpad: For D_to_A it is defined as 0% and 100% - Todd: Then regular [Ramp] is still broken - Arpad: If trise/tfall is zero it amounts to one timestep - Todd: What is the status of Parameter Trees? - Bob: I would be in favor of delaying a vote on this until that is discussed - Arpad showed BIRD 160 language regarding this - Arpad: It references BIRD 153, the example is from that - Maybe they should be voted together in open forum - Bob: It is not clear what Usage In means here - In AMI it is clear that it is with regard to the DLL - It is not good to have double meanings - Arpad: The only meaningful Usages are In and Info - There should be a different Usage for parameters controlling dependency tables - Bob: How would the tool know what to do with it? - Arpad: That is a good point - Todd: There is value in parameterizing - Without BIRD 153 we lose that - Arpad: We would only lose having parameters in the IBIS file - Todd: So an AMI file could have parameters and no DLL? - Ambrish: It could be a TXT file - Todd: Do the other AMI Reserved_Parameter and Model_Specific levels not apply? - Ambrish: It says they are not required - Todd: Something that is not an AMI parameter tree should not have an AMI extension - Arpad: References are required to show the path starting at root level - Mike L: Are values given as Format Range, etc? - Bob: This is not an AMI file, it does not conform to those rules - Todd: Then it should not have the AMI extension - Bob: There can be multiple trees in a file - Todd: AMI can have only one tree - Arpad: I will remove all references to BIRD 153, and assume it is approved - Bob: We still have issues regarding BIRD 153 - Ambrish: If parameters are taken from other than an AMI file we have to specify it - Arpad: If we use AMI we have the Usage In problem - Usage Info is for the simulator - Todd: It is all for the simulator, there is no DLL to execute on it - It has to be clear that this is something different - Ambrish: We should be able to define it as AMI with exceptions - BIRD a53 could be integrated with this - Bob: BIRD 160 should not be approved until this is fixed - Walter: The trise/tfall issue should be fixed too - Arpad: We decided that that does not affect this BIRD - Todd: That only affects [Ramp], not D_to_A - Mike L: The examples here should have the Model_Specific tree level inserted - Ambrish: That will not be required for these files - Arpad: If nothing else we can support literal values specified in the file - Bob: We could make it illegal to reference an AMI file AR: Arpad update BIRD 160.1 draft to address parameter tree issues ------------- Next meeting: 23 Apr 2013 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives